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Architecture for server extension. 



@ A server extension architecture provides 
means for intercepting input events and output 
protocol requests. Remote terminal emulation 
on an XWindows system is possible. The 
architecture comprises a portion of memory in 
the server extension which is identical to a 
portion of memory in the server where the 
server stores the addresses of input and output 
handling routines. By swapping these addres- 
ses with addresses in the server extension por- 
tion of memory, the server extension intercepts 
Input and output, for monitoring a server or an 
application program or controlling a works- 
tation. The server extension architecture is op- 
erated under the control ci an application 
program. 
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ARCHITECTURE FOR SERVER EXTENSIOS^ 



Reld of the Invention 

This Invention relates generally to architecture for a server extension used in a computer system and In 
5 particular to an architecture for a server extension for intercepting input events and protocol requests generated 
by an application program. The intercepted input events and protocol requests are subsequently used for any 
purpose, for example detennining the time lapse between the input event and the protocol requestfor evaluating 
the performance of the server and/or the application program. 

10 Background 

The server is the part of a computer system's architecture that functions as the internee between the conv 
puter or central processing unit and the user. It is desirable to test or evaluate the performance of the server 
for various purposes. For example, long delays between a user input and the system response can be detected 

15 and subsequently eliminated. Similarly, it is desirable to test and evaluate application programs running on the 
central processor unit of the computer for many purposes. 

Common methods of performance testing a server involve the use of video cameras or stop watches. In 
one such method the user or operator working at a terminal and the terminal screen are filmed by a video canv 
era. Thereafter the video Is replayed on a machine that displays time as a function of the film speed. Perform- 

20 ance metncs are then calculated based upon the difference between the displayed time of a starting film event 
and an ending film event The performance metrics for each timed event are then recorded. In another method, 
the step of calculating perfomiance metrics comprises manually timing response times with a stop watch. In 
either method, the perfomnance metrics for all of the timed events are then analyzed to determine the perform- 
ance of the applications or server. This same approach is also used to detenrnine the performance of the server 

25 for a single orspedfic input event This procedure is time-consuming, tedious, and prone to error. Furthwmore, 
this procedure requires actual operation by the user at a workstatk)n. Thus, simulated user input is impossible. 
Furthermore, since actual user input is inconsistent from one operation to the next, it is impossible to have con- 
sistent input from run to run. 

Another way of testing the performance of an application program or a server in response to input events 

30 or protocol requests Is with remote terminal emulation (RTE). RTE dispenses with a live user or operator for 
sending input to the server or the application program and replaces the operator with software generated input 
events which are loaded onto the server input event queue. However, prior attempts at RTE on servers of the 
X window type systems have faBed to provide a way to intercept output generated protocol requests by the 
server or the application. Furthenmore, none of these attempts have supported receiving simulated input from 

35 a remote source, i.e., a source that sends input over a non x transport link, such as network or asynchronous 
tenminal line. Thus, these prior attempts at RTE cannot test system configurations involving networks, modems 
and other peripheral devices. 

SUMMARY OF THE INVENTION 

40 

The present invention resides in architecture for a server extension used in a computer system. An exten- 
sion is a software module that performs server functions and has access to the server variables but is not a 
permanent part of the server. The server extension intercepts user input evente before they are received by 
the application program (also called a client), writes or stores information about the input, including the type of 

45 Input and the time it was intercepted, into a client defined location. The client defined location can be any type 
of storage such as a sequential file. The storage can be local or at a remote location and be connected over a 
modem line, a terminal line or a network line. Furthenmore, the server extenston intercepts output protocol 
requests generated by the application program before they result in visible changes to the screen display of a 
tenminal. An output protocol request is a signal generated by an application program and sent to the server, 

50 which causes the server to draw text or graphics on the screen of a tenminal. The server extension also writes 
or stores information about the output protocol request including the type of request and the time It was Inter- 
cepted, into a client defined location. The client defined location can be any type of storage such as a sequential 
file. The storage can be local or at a remote location and connected over a modem line, a terminal line or a 
network line. Finally, the server extension Is capable of receiving input from user operated Input devices such 

55 as the mouse or keyboard of a workstetion or simulated input from the controlling dlent 

The invention In its broad fonm resides in a computer system comprising : a central processing unit ; an 



2 



EP0430 708A2 



operating system ; one or more input drives for entering user-defined inputs into said computer system at the 
location of said tenninal ; one or more output drives for displaying test or graphic figures ; a computer program 
which runs in an interactive mode ; means (X Trap) to intercept said user-defined inputs between their entry 
by the user and their receipt by said computer program ; and means to intercept output instructions between 

5 said computer program and said one or more output drives. 

The server extension architecture as described herein intercepts input events and protocol requests which 
are used to enable the controlling client to monitor a server or the application program or to control a workstation 
for example testing the perfbnmance of applications, system configurations, a nd user interfaces. The data struc- 
tures of the server extension architecture are configured in a portion or block of memory and mimic or are sut>- 

10 stantlally Identical to the data structures of the server which are configured in a different portion or block of 
memory, in addition the server extension architecture of the present invention is operated under the control of 
the dient or applk^atton program. Thus, while the server extension architecture is descrit>ed in relation to the 
well known X server operating system program, it can also be implemented with any other operating system. 
The server extension architecture also provides RTE, remote terminal emulation and is capable of receh^ing 

15 simulated input from a remote source. For example the server extension architecture provides RTE capability 
for the X Window System which Is a well known operating system documented in R.W. Scheiffler, J. Getlys, 
and R. Newman. X Window System. Digital Press (1988). The server extension architecture also provides a 
quick, inexpensive means for software regression testing, and competitive or interoperability testing of appln 
cations among different hardware and software platforms. The server extension architecture also facilitates 

20 computer-based instructions where it is important to monitor a user's interaction at a terminal and be able to 
demonstrate correct interactions. It further facilitates trade show demonstrations where the demonstrator need 
not understand the application being demonstrated or needs to concentrate on the customer rather than the 
demonstration. As is apparent from the above examples the server extension architecture of the present inven- 
tion can be used for a wide variety of purposes which will be apparent to those skilled in the field. 

25 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more detailed understanding of the invention may be had from the following description of a preferred 
embodiment, given by way of example and to be understood in conjunction with the accompan^ng drawing 
30 wherein : 

FIG. 1 shows the general operation of the server extension of a prefenred embodiment of this invention 
in use with a computer system. 

FIG. 2 shows the data structures of the server extension of this invention as well as the data structures 
of the X server which the extension has access to. 
35 FIG. 3 is a process flow diagram showing an application program implementation of the server exten- 
sion in one mode of operation. 

FIG. 4 is a process flow diagram showing an application program implementation of the server exten- 
sfon in another mode of operation. 

40 DESCRIPTION OF THE PREFERRED EMBODIi^ENT 

FIG 1. shows the general operation of the server extension architecture of a preferred embodinr>ent of the 
present invention in use with basic components of a computer system. A software configuration runs on a cent- 
ral processing unit 1 0 that Interacts with an X server 1 2. The X server is a well known operating system program 

45 that controls a user interface of the terminal or work station 14 and utilizes windows 1 6 and a mouse 1 8 in addi- 
tion to standard user Interface elements such as a keyboard 20 or text The X server 12 can support "exten- 
sions,*" or software nrK)dules that have access to X server variables, but which are not permanent parts of the 
X server. The extension 22 of this embodiment is referred to as the *%Trap extensfon." Those skilled in the art 
will know how to apply the teachings of tiiis embodiment to other operating systems and servers. 

50 A plurality of application programs 24A tiirough 24N can be run on the central processor unit (CPU) 10. 
One applicatton program or client 24N running on tiie CPU 10 acts as tiie controlling client of the XTrap exten- 
sion 22, which is a software extension of ^e X server 1 2. Known software modules or extensions that perfonn 
operating system functions are controlled by tiie server, the XTrap extension 22 is controlled by a single appli- 
cation program or client 24N. The controlling client 24N sets the parameters of the XTrap extension 22 and 

55 tums the XTrap extension 22 on and off. User input from the mouse 18 or tiie keyboard 20 is initially received 
by the X server 12. The present invention is also applicable to operating systems witii other input devices, as 
well as to op^ting systems with only one type of input device. The XTrap extension 22 intercepts the input, 
reformats a copy of the Input for use by its Vrite" routine, as more fully set forth below, and sends the original 
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input to the server 12 for normal processing. Ultimateiy, the client 24A to 24N-1 , the client being nnonitored or 
controlled, receives the original input and handles it according to its particular implementation. 

Any client 24A through 24N-1 generates output in the form of protocol requests, usually to control some 
kind of screen output at the workstation 14. The controlling client 24N can simultaneously display the same 

5 output on a screen at another workstation (not illustrated). These output protocol requests cause the server to 
draw text, lines or other graphic elements on the display screen of the workstation 14. Although In the prefiBrred 
embodimentthe only communications between the application programs and the X server that XTrap intercepts 
are output protocol requests, the present invention could be used to intercept any communfcation between any 
client and the server. The X server 1 2 receives output protocol requests from an application program 24A-24N- 

10 1, and the XTrap extension 22 intercepts them before the X server processes them. As with input, the XTrap 
extension refonnats a copy and sends the original back to tiie X server. Ultimately, the output reaches the 
screen of the workstation 14 to control the form of text, lines or erasures. 

The XTrap extension 22 calls a "write" subroutine that is part of the code of the extension. XTrap has a 
different "write" routine for every communication channel over which XTrap can communicate with the control- 

15 ling client The controlling client can be at a remote location from XTrap, such as at the other end of a networic 
line. This "write" routine sends the collected infomnation on inputs and outputs to the controlling client 24N or 
to a sequential file. 

Fig. 2 shows the architet^re of the XTrap extension and ttie server. The present invention Is not limited 
to use with an architecture of this type, but will woric on any operating system architecture that calls subroutines 

20 to process input and protocol request The X server processes keyboard data by sending it to the routine whose 
address is stored In the "KeyBoard ProcesslnputProc" storage location 28. The server handles mouse input In 
a similar way, i.e., by referencing the "Pointer ProcesslnputProc" storage location 30. The X server processes 
output protocol requests by sending the appropriate informatkin to the routine whose address ts stored in a 
specified element of the "ProcVector* an^y 32. 

25 The XTrap extension contains data structures that are one half the size as the X server data structures, 
however the size can be smaller or even identical. The XTrap data structures are also lakJ out in memory in 
the same or substantially the same configuration as the X server's data structures. A person skilled in the art 
will know how to use the teachings of this Invention to provide means for mimicking the architecture of another 
operating system so that they call extension subroutines for processing input (and/or output) instead of its own, 

30 while at the same time providing a means for returning the operating system to its nonmal state after the use 
of the extension is completed. When XTrap is configured for intercepting keyboard input, the X server's storage 
location, "KeyBoard ProcesslnputProc" 28 contains the address of the XTrap routine that handles keyboard 
input, and the XTrap version of this storage space, called "keyboanLinputproc" 34, stores the address of the 
X server's input-handling routine. If XTrap is configured for intercepting mouse-input the X-server's storage 

35 location, "Pointer ProcesslnputProc" 30 contains the address of the XTrap routine that handles mouse input 
and the XTrap version of this storage space, called "pointer-inputproc" 36. stores the address of the X-server's 
input handling routine. 

As can be seen from the above configuration. XTrap will intercept keyboard and rrrause input As explained 
above, when the X server receives keyboard input it calls the routine whose address is stored in "KeyBoard 

40 ProcesslnputProc" 28, and when it receives mouse input it calls the routine whose address is stored in "Pointer 
ProcesslnputProc" 30. Since during the implementation of XTrap these storage locations 28 and 30 contain 
the addresses of XTrap routines, the keyboard and mouse input is sent to the XTrap extension. 

The XTrap extension intercepts client-generated output protocol requests by swapping the address of the 
XTrap extenston output handling routine with the address of the X server output handling routine stored in data 

45 structure 32, referred to as "ProcVector". Each 4-byte value is an address of a routine that handles an output 
protocol request In the preferred embodiment there are 256 4-byte addresses, but it Is within the scope of the 
present invention to have smaller or larger arrays. Array element 42 contains the address for the routine that 
handles an "ImageTextS" request This routine draws a single string of text on thesCTeen. If XTrap is configured 
for intercepting the "lmageText8" output protocol request the value stored at this location is the address of an 

50 XTrap routine that draws a single string of text on the screen. This routine is called "extJmagetext8". The 
address of the "ImageTextS" routine is stored at the corresponding element 44 of the "exLprocvector" array 38 
which is XTrap's version of the X server's "ProcVeclor" data structure 32. Thus, when the X server receives a 
request from any client to draw a string of text, it calls the routine that has Its address stored in the element 42 
of "ProcVector" 32. While XTrap is active that address will be the address of the XTrap routine, "exLimagetexlS" 

55 normally stored at element 44. 

Other output protocol requests include for example, "PolyTextS", which draws more than one string of text 
on the screen, *'MapWindow", which prepares the server for drawing a window on the screen, and "Unmap- 
Window", which erases windows from the screen. The corresponding routines in the XTrap data struchire 38 
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are ^'exLpolytextS", exLunmapwindow" and "exUnapwindow". Any other output protoc<rf request can be inter- 
cepted by the XTrap extension in a stmQar fashion. 

When the XTrap extension intercepts input or output, it creates a copy of the input or output information 
that is formatted for processing by XTrap's "write" routine that the client has configured. While XTrap is turned 

5 "on", the address of the "write" routine is stored in the "xtrap.write" vector 40. When XTrap is turned "off," "xtrap. 
write** holds the address of a null routine, i.e., a routine that does nothing but return control to XTrap. In either 
case, if XTrap is configured to intercept any input or output, it sends a copy of fomiatted input or output to the 
routine whose address is stored in "xtrap.write". 

The data structure "exLenvlronment" 48 contains the XTrap internal variables. The variable "swap^tate" 

10 is a bitfield which indicates which output protocol requests and input events are being intercepted. The "genflgs" 
variable is a bit field of general extension flags that enable and disable various features such as timestamp 
calculation, "windowJd** processing, and output fonnat (i.e.. binary or ASCII). "WindowJd" processing, when 
enabled, causes XTrap to report which window is the object of a "MapWindow" or "UnmapWindow" output pro- 
tocol request The variable "osflg" Is a bit field of implementation specific flags. The variable "imagcnt" holds 

15 the maximum number of characters that XTrap saves from a text string when XTrap intercepts an "ImageText" 
or a "PolyText" request The saved characters are part of the information on output protocol requests that XTrap 
sends to the "write" routine. If "imagcnt" is negative, the characters are saved from the beginning of the string; 
if "imagcnt" is positive, the characters are saved from the end of the string. 

The variable "polycnf holds the maximum number of strings XTrap should process when XTrap intercepts 

20 a "PolyText" request When the strings are processed, "imagcnt" characters are sent to the "write" routine. If 
"polycrrt" is positive, strings are processed from the beginning of the string list ; if "polycnt" is negative, strings 
are processed from the end of the string list The variable "Lcomm" contains an identifier for the communication 
channel being used for simulated input to XTrap. The variable "o.comm" contains an identifier for the communi- 
cation channel being used for output from the XTrap extension. Finally, the variable "writeJo" holds the pointer 

25 to the "write" routine that is placed in "xtrap.write" when XTrap receives a STARTJO request 

FIGS. 3 and 4 ara process flow diagrams showing an application program or controlling client configuration 
and use of the XTrap server extension in two different modes of operation. FIG. 3 is a process flow diagram 
showing the operation of the XTrap server extension when recording input events or output protocol requests 
are generated during a live user session refenred to as the record mode of operation. RG. 4 is a process flow 

30 diagram showing the operation of the XTrap server extension using the RTE, remote terminal emulation capabi- 
lities to simulate a live user session using simulated input events and waiting for incepted output events referred 
to as the playback mode of operation. The controlling client communicates with the XTrap extension by sending 
a data structure to the server via the XUB xflush macro, which is documented in R.W. Scheiffier, J. Gettys. 
and R. Newman. - X Window System, published by Digital Press (1 988). The server then sends the data struo- 

35 ture to the extension. Table 1 below shows the fonnat of the data structure "xXtrapReq". 

Table 1 

The xXtrapReq data structure (short version) 

40 

The first field, "reqType," identifies which XTrap extension the "xXtrapReq" data stnjcture should be passed 
to. The dient collects this identifier by calling "xQueryExtension." which is documented in R.W. Scheiffier. J. 
Gettys. and R. Newman, entitled X Window System of Digital Press (1988). The second field. "minor_opcode," 
contains the identifier for the specific XTrap extension request the client is sending. Refemng again to FIG. 2. 
45 the "exLrequesLvector" array 46 contains a dispatch table that XTrap uses to look up the "minor.opcode" and 
to call the appropriate request processing routine. The third field, "length" is always 9 for XTrap requests. The 
fourth field, "data" is a union configured differently for each request It contains the data specific to the request 
being sent The present invention is not limited to the use of xflush for communicating with the extension. 

50 
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Table 1 

The xXtrapReq data structure (short version) 



t5 CXW)S r«qTyp«; /• Zxt^njion MAjor opcode •/ 

BTTX a±nor_opcod«; Klnor cpcod* of r#qu««t •/ 

CXJU)lg l«ngrh SIS; /• InitlAilz*d with 9 •/ 



\mion 
{ 

union c£ v^rioua r»<iu*«t dAtA. tcruccur 

} 



} 



25 

Referring again to FIG. 3, the first step a client takes in configuring XTrap is to obtain the extension identifier 
by calling "xQueryExtension," which is documented in R.W. Scheiffler, J. Gettys, and R. Newman, entitled X 
Window System, of Digital Press (1988). Next, the client requests the XTRAP J^SET request by setting the 
various fields of the "^trapReq" structure and sending it to the server via the xflush macro. The XTRAP_RESET 
30 request causes the extension to prepare itself for use by a new client If a dient is already using the extension 
and has previously configured itself as the controlling client, XTrap will check the "force" flag in the request 
The "force" flag is part of the request-specific infonmation that is sent to XTrap in the "RESET" union field of 
"xXtrapReq." (See Table 2) 

35 Table 2 

The xXTrapReq data structure 

(long version - showing contents of the "data" union 



If the "force" flag is set, XTrap will reset itself and remove itself from the control of the other client If the 
"force" flag is not set, XTrap will return an enror code to the client 
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Table 2 

The xXTrapReq data structure 
10 (long version - showing contents of the "data" unior 
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30 
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45 

A client can prevent another client from gaining accidental control of an extension by setting the "control" 
flag during an XTRAP_RESET request. Setting the "control" flag causes the XTrap extension to Ignore any sub- 
sequent XTRAP_RESET requests from another client unless the other client sets the "force" flag. The "control" 
flag, like the "force" flag is a part of the "RESET union. 

so When the XTrap extension receives an XTRAP_RESET request, it resets XTrap's internal variables and 
flags to their default values, and undoes any conflguration for intercepting input or output All client programs 
send an XTRAP_RESET before they stop. 

Once the XTrap extension is reset, the client sends an XTRAP.CONFIG request to set up the kind of Input 
and output the extension is to intercept For the XTRAP^CONRG request, the "data" union of xXTrapReq" has 

55 the stnjcture shown in Table 3. 

Table 3 
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The CONFIG union 



Table 3 
The CONFIG union 



10 



15 



typ#<l*f acruct ccnfig /• u»»<l by X7KXI CCNTIC »/ 

FLAGS flAg»; 

BITS bits; - 

CAi^8 opcod«^count ; 

CXiir>8 p«d_lbyT«; 

INT15 pad^Iword; 

OJU>a ILmz (KJUC_LI5TJ ; 
1 COKTIG; 



The 'Hags" field is used to enable and disable input and output interception and is shown in Table 4. 
35 Table 4 

The "flags" field of the CONFIG union 

Setting the "vjcbd" flag causes XTrap to set the state of keyboard input interception according to the state 
40 of the "sjcbd" flag. If "sjcbd" is on, keyboard input interception is enabled. It it is off, keyboard-input interception 
is disabled. Mouse input is similarly controlled with the V.ptr" and the "s_ptr" flags. The pair of flags, "v.opcodes" 
and "s_opcodes", act in the same way to enable or disable the interception of output protocol requests listed 
in the "lisffield of the "CONFIG" structure shown in Table 3. 

The XTRAPXONFIG request can also configure the extension to take a millisecond timestamp of any inter- 
ns cepted input or output protocol request. XTRAP_CONFIG also provkies some control over the fonm of output 
generated by XTrap, namely over the choice between ASCII fomiat and binary formaL 

When the XTrap extension receives an XTRAP.CONRG request, it performs the swap operation that 
exchanges the 
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Table 4 

The "flags" field of the CONFIG union 
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address of the XTrap input or output processing routine with the address of the X server's input or output pro- 
cessing routine, for each type of input and output protocol request selected by the dient For example, if the 
client set flags VJcbd" and s_kbd" in its XTRAP.CONFIG request, then, referring to FIG. 2, XTrap will exchange 
the "KbdProc" pointer in vector "KeyBoard ProcesslnputProc'*28forthe pointer "xtrapjceyboard" in "keyboard. 
5 inputproc" 34. If the client set flag "VJdjd" but left flag "sJcbd" unset, the two pointers would be unswapped. 
The XTRAP_RESET request also causes XTrap to unswap KeyBoard ProcesslnputProc" and "bctrapjcey- 
board.". 

Next, the client sends a CONFIGJO request to XTrap to specify over what kind of comn^unication channel 
to send Infonnatlon on collected input and output to the controlling dient When XTrap receives this request, 

10 it sets its internal variable "writejo" (48 on FIG. 2} to the value of a pointer to a Vrite" routine. This routine Is 
used to send the information on intercepted input events and output protocol requests to the controlling dient 
via the configured communication channel. In record mode, the dient records the infonmation in a sequential 
file. In playback mode, the controlling client uses the information received via the configured ^vrite* routine to 
verify that simulated input was sent to the server. This allows the controlling client to ensure that the server 

15 will ignore Input from the keyt>oard or the mouse when, for security or other reasons, this is necessary. The 
dient also uses the information to monitor output protocol requests to ensure that it waits to send the next input 
event until after the last output protocol request has been processed. In playback mode the controlling dient 
may also record the Information to a sequential flie. For example, rf the last output protocol request was a 
request for a "$* prompt, the client must wart until the appears on the screen before It sends the next input 

20 event 

In playback nnode, the CONFIGJO request is made to Implement Remote Terminal Emulation (RTE). Table 
6 shows the structure of the "data" union of "xXtrapReq" for the CONRGJO request 

Table 5 

25 

The lO union 

The "transport" field contains a dedmal value describing the type of communk;atk)n channel being config- 
ured. Examples of communication channels include asynchronous tenninal lines, sequential files, TCP/IP net- 
so works, VMS mail box connection. 
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Table 5 
The 10 union 

S 
10 



15 



#d«fln# Z0_Bt7IT»_<ZIX 21 
20 typ^f atruct lo /• u»*d by COlcrio 10 •/ 

CUDt tr&n«pcrt; 

CAJU>i dirsetion; 

C«D1< pad »; 

1TT» buffer CIO_»ajTW_f IMl 

} 10; 

/♦ 

^ • V&lu«0 for M9m In th« dirvction fi«Id. 

* thm conunieation aodt jrp#cifl#d In thm 

* transport fi«ld will b% M$md to confiTur^ 

* thm input and/or output channels ap^cifl^d 
35 * in thm direction fi»ld. 

♦/ 

#dafin« IO_OIK_Ill (1«0) /• ConflTor^ for input 

|d«fia# Io""oxk'"out /• Configure for output •/ 

#d0fin« zo^wTmon {lo d» iw i io dir oot) 



XLIB transport and DECnet Task-toTask Communication. Input sent via XLIB transport is sent via the xflush 

macro using a SIMULATEJCEVENT request or the MOVE-POINTER request, discussed below. It can be seen 
45 that by using sequential files as the source for keyboard and mouse input, an application program can be per- 

fbnmance tested without a live user. Furthennore, software regression and comparative testing are simplified. 

The "direction" field specifies whether the CONFIGJO request applies to input, output or both. 

Once the XTrap extension is configured, the dient makes the STARTJO requesfKBto start I/O over the 

communlcatton media configured with the CONFIGJO request and to initiate the ^vrite" routine that sends input 
so and output information to the controlling client The only data specified with this request are (1) the number of 

characters the extension should save from an intercepted text string that is part of an output protocol request, 

and (2) the number of text strings the extension should process when the extension intercepts "PolyTextB". 

output protocol request that request the server to draw more than one string of text on the screen. (See Table 

6). 

55 

Table 6 

The START union 

11 
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When the controlling client has completed its remote control or monitoring of a workstation that requires 
XTrap implementation, the client should send a STOP JO request to the XTrap server extension via the xflush 
macro. This causes character flow to and from the 10 channels to stop. Before the client is ready to stop execu- 
tion, it should send an XTRAP_RESET request to the XTrap extension in order to unswap any input or output 
5 processing routines. 

The controlling client can send the XTRAPJNFO request whenever the contrdiing client needs to know 
the v^ues of any internal variables. 

The controlling dient can use the SIMUU\TEJ(EVENT and the MOVEJ'OINTER requests in playback 
mode to send input to the X server via XUB. Table 7 shows the fonmat of the "data" union of the "xXtrapReq* 
10 structure for use with SIMULATEJCEVENT and MOVE_POINTER. SIMULATEJCEVENT is used to send 
keyboard events and mouse elide events. 

Table 6 

15 

The START union 



typ«d«f Jtruct »t4rt 

{ 

25 INXl^ Inag^count; 

1KT16 poly'"count; 

30 Table 7 

The XINPUT union 

M0VE_P0INTER is used to send mouse motion events. The variable "type* is set to the value of an iden- 
35 tifierfor the type of event being sent, which, in the case of a MOVE-POINTER request, ts a mouse motion event 
The variable "detail** is set for the value of an identifier for the key or mouse button pressed or released in a 
SIMULATEJCEVENT request. The variables "x" and V are set to the destination screen coordinates of the 
mouse cursor. 

The foregoing description of the invention has been presented for purposes of illustration and description. 
40 It is not intended to limit the invention to the precise forms disdosed, and obviously many modifications and 
variations are possible and envisaged in light of the above teachings. 



/• u»%d by snmr ro »/ 
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Table 7 
The XINPUT union 

5 



/♦ u««<i *l«o by MOVl^FOIKTXX •/ 

typ#d«f struct xinput 
{ 

CXADI typ«; 
CX^I d«t4ll; 

cx«)l« y; 

} XIWOT; 



25 Claims 



1 . A computer system comprising : an input device (20) for entering inputs into the computer system ; an input 
device ; a computer program ; characterised by means (22) to intercept the inputs between their entry into 
the computer system and their receipt by the computer program ; and means (22) to intercept output instruc- 

30 tions between the computer program and the output device. 

2. A computer syst^ as claimed in dalm 1 in which the means for intercepting the inputs includes an exten- 
sion having a memory structure comprising a block of memory configured substantially identically to a block 
of m^ory in a server ; extension input handling routines ; server input handling routines ; means for storing 

35 the address of the extension input handling routines in the block of memory in the server ; and means for 
storing the address of the server input handling routines in the extension memory structure. 

3. A computer system Including a central processing unit (CPU), a peripheral device which sends electronic 
signals to the CPU and receives electronic signals from the CPU, and a computer program whose instruc- 

40 tions are executed by the CPU which acts on the electronic signals sent by the peripheral device and sends 
the electronic signals which are received by the peripheral device ; characterised by means for intercepting 
the electronic signals. 

4. A method of intercepting signals between a server (12) and a peripheral (20) characterised by storing the 
45 address of input handling routines for the server in a block of memory contained within an extension unit 

(22) and storing the address of input handling routines for the extension unit in a block of memory in the 
server. 
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Server Side Data Structures 



32 



42 



ProcVector 



PolyTextS 
ImageTextS 



MapWIndow 
UnmapWindow 



KeyBoard 
ProcesslnputProc 



KbdProc 



Pointer 
ProcesslnputProc 
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PtrProc 



30 



Extension Side Data Structures 



ext^provector 



ext_request_vector 



0 1 0 

1 1 1 

2 1 2 




0 

38 2 


XTRAP_RESET 




XTRAPJNFO 




XTRAP_C0NF1G 




• 
• 


3 
4 


CONRGJO 




STARTJO 




externa pwlndow 
ext_unmapwlndow 


5 
6 
7 


STOPJO 


SIMULATE_XEVENT 


MOVE_POINTER 




ext_polytext8 


N In 


extJmagetextS 




• 
• 
• 
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ext environment 



keyboardjnputproc 
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k 3- 

xtrap^keyboard 



swap state 
osfig I genfig 
imagcnt ] polycnt 
o_comm I l_comm 
write lo 
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pointerjnputproc 



xtrap_write 



xtrap_polnter 
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CONTROLUNG CLIENT 
PREPARES TO SEND 
RESET REQUEST 




SEND ERROR TO 
CONTROLUNG CUENT 



RESET INTERNAL 
VARIABLES 

DE-CONFIGURE PREVIOUS 
I/O INTERCEPTION 



3 



CONFIGURE I/O INTERCEPTION 
SWAP POINTERS 



I 



CONFIGURE COMMUNICATION 
CHANNEL, SELECT "WRITE" 
ROUTINE 



I 



TURN XTRAP "ON" 

4 



USER ENTERS INPUT 

AT MOUSE AND KEYBOARD 



I 



XTRAP INTERCEPTS INPUT 
CALLS "WRITE": RETURNS 
INPUT TO SERVER 



J. 



APPLICATION RECEIVES 
INPUT; GENERATES OUTPUT 
PROTOCOL REQUESTS 



XTRAP INTERCEPTS OUTPUT 
CALLS "WRITE"; RETURNS 
OUTPUT TO SERVER 



NO ^^HAS USER QUI! 
VPPUCATION 

YES 



TURN XTRAP "OFF"; 
RESET XTRAP 
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CONTROLUNG CUENT 
PREPARES TO SEND 
RESET REQUEST 




RESET INTERNAL 
VARIABLES 

DE-CONFIGURE PREVIOUS 
I/O INTERCEPTION 
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CONFIGURE I/O INTERCEPTION 
SWAP POINTERS 



1 



I 



CONRGURE COMMUNICATION 
CHANNEL, SELECT "WRITE" 
ROUTINE 



I 



TURN XTRAP "ON" 



CONTROLUNG CLIENT SENDS 
SIMULATED INPUT TO SERVER 



I 



XTRAP INTERCEPTS INPUT; 1 
VERIFY INPUT SOURCE; 
RETURN INPUT TO SERVER IF 
VALID 



SEND ERROR TO 
CONTROLUNG CUENT 



APPUCATION RECEIVES 
INPUT; GENERATES OUTPUT 
PROTOCOL REQUESTS 



XTRAP INTERCEPTS OUTPUT 
CALLS "WRITE"; RETURNS 
OUTPUT TO SERVER 




TURN XTRAP "OFF"; 
RESET XTRAP 
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